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FETTING, Administrative Patent Judge. 

DECISION ON APPEAL 

STATEMENT OF THE CASE 
Dushyant Sharma (Appellant) seeks review under 35 U.S.C. § 134 of a 
non-final rejection of claims 1-20, the only claims pending in the application 
on appeal. 

We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b) 
(2002). 
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1 We AFFIRM. 

2 

3 The Appellant invented a way for integrated electronic bill presentment 

4 and payment among billers, consumers, banks and other financial 

5 institutions in electronic commerce (Specification 1:3-7). 

6 An understanding of the invention can be derived from a reading of 

7 exemplary claim 1, which is reproduced below [bracketed matter and some 

8 paragraphing added]. 

9 1 . An electronic bill presentment and payment system, 

10 comprising: 

n [1] a database 

12 capable of storing data relating to a plurality of bills 

13 sourced from a plurality of billers, and 

14 corresponding to a plurality of consumers; 

15 [2] a bill data processor coupled to said database, 

16 said bill data processor being capable of converting data 

17 received from said plurality of billers 

18 into a format compatible with said database; 

19 [3] a bill report processor coupled to said database, 

20 said bill report processor being capable of allowing at 

21 least some of said plurality of billers 

22 to review and obtain reports in real time from 

23 data relating to said billers and 

24 the status of said biller's bills stored in said 

25 database; 

26 [4] a bill security element 

27 which prohibits access to said database 

28 by any entity not having encrypted access to said 

29 database; and 
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1 [5] a portal interface element coupled to said database, 

2 said portal interface element being capable of supporting 

3 a plurality of visual interfaces 

4 each associated with a different web portal or bill 

5 presentment and payment website, 

6 each visual interface being supported by a web 

7 portal or bill presentment and payment website 

8 different from other of said visual interfaces, 

9 each of said visual interfaces allowing a consumer 

10 to review and pay said consumer's bills and 

n thereby change information in said database 

12 only if said consumer has been authorized 

13 access to said database by a credit verifier. 

14 This appeal arises from the Examiner's non-final Rejection, mailed 

15 December 27, 2006. The Appellant filed an Appeal Brief in support of the 

16 appeal on June 21, 2007. An Examiner's Answer to the Appeal Brief was 

17 mailed on October 4, 2007. A Reply Brief was filed on December 4, 2007. 

18 PRIOR ART 

19 The Examiner relies upon the following prior art: 

Kamen US 6,421,067 Bl Jul. 16, 2002 

Haseltine US 6,578,015 Bl Jun. 10, 2003 

20 REJECTIONS 

21 Claims 1-16 and 18-20 stand rejected under 35 U.S.C. § 102(e) as 

22 anticipated by Haseltine. 

23 Claim 17 stands rejected under 35 U.S.C. § 103(a) as unpatentable over 

24 Haseltine and Kamen. 
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1 ISSUES 

2 The issues pertinent to this appeal are 

3 • Whether the Appellant has sustained its burden of showing that the 

4 Examiner erred in rejecting claims 1-16 and 18-20 under 35 U.S.C. 

5 § 102(e) as anticipated by Haseltine. 

6 • Whether the Appellant has sustained its burden of showing that the 

7 Examiner erred in rejecting claim 17 under 35 U.S.C. § 103(a) as 

8 unpatentable over Haseltine and Kamen. 

9 The pertinent issues turn on whether Haseltine describes a system having 

10 the capabilities recited in argued claims. 

1 1 FACTS PERTINENT TO THE ISSUES 

12 The following enumerated Findings of Fact (FF) are believed to be 

13 supported by a preponderance of the evidence. 

14 Haseltine 

15 01. Haseltine is directed to electronically presenting bills to 

16 customers while preserving the billers' corporate identity, as 

17 embodied in the "look-and-feel" of the bills presented to 

18 customers (Haseltine 2:57-61). 

19 02. Haseltine' s billers have the option of transmitting bill data and 

20 bill format data to an electronic presentment and payment 

21 database. The bill data may include a customer identifier, an 

22 amount due and a date due for each of the biller's customers that 

23 have opted to pay their bills electronically. The bill data stream 

24 may be coded according to any number of formats such as the 
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1 Open Financial Exchange (OFX) format, ASCII, extensible 

2 Markup Language (XML), print streams or other legacy or 

3 proprietary formats. The bill format data may include HTML- 

4 formatted data configured to mimic the "look-and-feel" of the 

5 biller's traditional paper bills, when rendered on a display device. 

6 Alternatively, or in addition to HTML, the bill format data may 

7 include functionality programmed in Extensible Markup 

8 Language (XML) (Haseltine 4:53 - 5:29). 

9 03. A bill data validation procedure may be carried out to insure the 

10 integrity of the bill data 402 transmitted by the biller. This 

1 1 validation procedure may include, for example, verification of the 

12 customer's identity, verification of the integrity of the transmitted 

13 data and/or verification that all required fields (such as amount 

14 and/or date due, for example) have been properly populated 

15 (Haseltine 5:43-49). 

16 04. Haseltine provides status tables that may be viewed by 

17 customers. As the name implies, the status tables track the status 

18 of the bills presented to the customers such as whether a 

19 customer's bills have been viewed, paid, have been submitted or 

20 are pending. Other indicia indicative of the status of the 

21 customers' bills may also be included in the status tables 

22 (Haseltine 6:10-21). 

23 05. Haseltine allows customers to dispute bills by sending a 

24 message to a customer service representative. The biller of the 

25 disputed bill may then log onto the system and take appropriate 

26 action (Haseltine 6:22-26). 
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1 06. Haseltine provides a template manager when the customer logs 

2 on to view his or her bills. Haseltine describes a template selection 

3 rule that compares the system date (i.e., the present date) with the 

4 bill due date and causes the template manager to select a biller- 

5 specific "overdue bill template" when the system date is greater 

6 than the bill due date and a "current bill template" otherwise. The 

7 template manager may also evaluate Boolean expressions such as 

8 AND, OR, etc. to select a template that is appropriate to the bill 

9 data (Haseltine 8:28-40). 

10 07. Haseltine allows a customer to log onto a Web site of a biller 
n through the Internet via an HTML Secure Sockets Layer (SSL), 

12 which is a high-level security protocol that insures security of data 

13 transmitted over the Internet, and is well known and used by many 

14 commerce servers on the Web. Popular Web Browsers currently 

15 support SSL, with varying levels of encryption. In this case, the 

16 biller may maintain a database 400 (FIG. 4) in an appropriate 

17 server. Alternatively, the biller may have in-house payment 

18 processing capabilities, in which case the customer directly logs 

19 onto the Web site of the biller to view and/or pay his or her bills 

20 for that biller (Haseltine 9:51- 10:10). 

21 08. Haseltine describes how bill consolidators exist, which allow 

22 customers to electronically log onto a single site on the Web and 

23 pay bills originating from a number of individual billers. Such 

24 consolidators may be generally categorized as thin consolidators 

25 or thick consolidators. Thin consolidators typically carry only bill 

26 summaries and refer the customer to the biller's own Web site for 
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1 further detailed bills and/or further customer service, such as to 

2 discuss a disputed bill. Thick consolidators typically carry the 

3 biller's entire customer data and often act as their own payment 

4 processors (Haseltine 2:30-49). Haseltine allows thick and/or thin 

5 consolidators to preserve the "look-and-feel" of their billers' bills 

6 while providing the customer with a flexible and integrated bill 

7 presentment and payment infrastructure (Haseltine 10:11-11 :22). 

8 09. Haseltine' s system allows generating reports to billers and 

9 administrators (Haseltine 12:22-25). 

10 10. Haseltine describes using input devices, such as a fingerprint 

1 1 reader, a retina scanner and/or other biometric information 

12 measuring and/or acquiring devices to assist in the authentication 

13 of customers to the electronic bill presentment and payment 

14 database (Haseltine 13:15-22). 

15 Kamen 

16 11. Kamen is directed to a television electronic programming guide 

17 (EPG) with a graphic interface (Kamen 1:3-4; 3 : 12-23). 

18 12. Kamen describes a user modifying the surfaces of EPG graphic 

19 elements. This alteration of the video surface can be in the form of 

20 zooming in on the video surface by changing its position in virtual 

21 3D space or changing the color of the video surface by changing 

22 specular, ambient, and directional lighting. By altering the various 

23 video and data surfaces, the surfaces (including pictograms) can 

24 be observed from different perspectives. This facilitates a viewer 
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1 zooming in on the various pictograms to better identify what kind 

2 of program they represent (Kamen 3:50-67). 

3 Facts Related To The Level Of Skill In The Art 

4 13. Neither the Examiner nor the Appellant has addressed the level 

5 of ordinary skill in the pertinent arts of systems analysis and 

6 programming, financial transaction systems, and network 

7 communication. We will therefore consider the cited prior art as 

8 representative of the level of ordinary skill in the art. See Okajima 

9 v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001) ("[T]he 

10 absence of specific findings on the level of skill in the art does not 

1 1 give rise to reversible error 'where the prior art itself reflects an 

12 appropriate level and a need for testimony is not shown'") 

13 (quoting Litton Indus. Prods., Inc. v. Solid State Sys. Corp., 755 

14 F.2d 158, 163 (Fed. Cir. 1985). 

15 Facts Related To Secondary Considerations 

16 14. There is no evidence on record of secondary considerations of 

17 non-obviousness for our consideration. 

18 PRINCIPLES OF LAW 

19 Claim Construction 

20 During examination of a patent application, pending claims are 

21 given their broadest reasonable construction consistent with the 

22 specification. In re Prater, 415 F.2d 1393, 1404-05 (CCPA 1969); In 

23 re Am. Acad. ofSci. Tech Or., 367 F.3d 1359, 1364 (Fed. Cir. 2004). 
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1 Limitations appearing in the specification but not recited in the claim are 

2 not read into the claim. E-Pass Techs., Inc. v. 3Com Corp., 343 F.3d 1364, 

3 1369 (Fed. Cir. 2003) (claims must be interpreted "in view of the 

4 specification" without importing limitations from the specification into the 

5 claims unnecessarily). 

6 Although a patent applicant is entitled to be his or her own lexicographer 

7 of patent claim terms, in ex parte prosecution it must be within limits. In re 

8 Corr, 347 F.2d 578, 580 (CCPA 1965). The applicant must do so by placing 

9 such definitions in the Specification with sufficient clarity to provide a 

10 person of ordinary skill in the art with clear and precise notice of the 

n meaning that is to be construed. See In re Paulsen, 30 F.3d 1475, 1480 

12 (Fed. Cir. 1994) (although an inventor is free to define the specific terms 

13 used to describe the invention, this must be done with reasonable clarity, 

14 deliberateness, and precision; where an inventor chooses to give terms 

15 uncommon meanings, the inventor must set out any uncommon definition in 

16 some manner within the patent disclosure so as to give one of ordinary skill 

17 in the art notice of the change). 

18 Anticipation 

19 "A claim is anticipated only if each and every element as set forth in the 

20 claim is found, either expressly or inherently described, in a single prior art 

21 reference." Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 

22 631 (Fed. Cir. 1987). "When a claim covers several structures or 

23 compositions, either generically or as alternatives, the claim is deemed 

24 anticipated if any of the structures or compositions within the scope of the 

25 claim is known in the prior art." Brown v. 3M, 265 F.3d 1349, 1351 (Fed. 

26 Cir. 2001). "The identical invention must be shown in as complete detail as 
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1 is contained in the ... claim." Richardson v. Suzuki Motor Co., 868 F.2d 

2 1226, 1236 (Fed. Cir. 1989). The elements must be arranged as required by 

3 the claim, but this is not an ipsissimis verbis test, i.e., identity of terminology 

4 is not required. In re Bond, 910 F.2d 831, 832 (Fed. Cir. 1990). 

5 Obviousness 

6 A claimed invention is unpatentable if the differences between it and 

7 the prior art are "such that the subject matter as a whole would have been 

8 obvious at the time the invention was made to a person having ordinary skill 

9 in the art." 35 U.S.C. § 103(a) (2000); KSR Int'l Co. v. Teleflex Inc., 127 

10 S.Ct. 1727, 1729-30 (2007); Graham v. John Deere Co., 383 U.S. 1, 13-14 
n (1966). 

12 In Graham, the Court held that that the obviousness analysis is 

13 bottomed on several basic factual inquiries: "[(1)] the scope and content of 

14 the prior art are to be determined; [(2)] differences between the prior art and 

15 the claims at issue are to be ascertained; and [(3)] the level of ordinary skill 

16 in the pertinent art resolved." 383 U.S. at 17. See also KSR, 127 S.Ct. at 

17 1734. "The combination of familiar elements according to known methods 

18 is likely to be obvious when it does no more than yield predictable results." 

19 Id, at 1739. 

20 "When a work is available in one field of endeavor, design incentives 

21 and other market forces can prompt variations of it, either in the same field 

22 or a different one. If a person of ordinary skill can implement a predictable 

23 variation, § 103 likely bars its patentability." Id. at 1740. 

24 "For the same reason, if a technique has been used to improve one 

25 device, and a person of ordinary skill in the art would recognize that it would 
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1 improve similar devices in the same way, using the technique is obvious 

2 unless its actual application is beyond his or her skill." Id. 

3 "Under the correct analysis, any need or problem known in the field 

4 of endeavor at the time of invention and addressed by the patent can provide 

5 a reason for combining the elements in the manner claimed." Id. at 1742. 

6 ANALYSIS 

7 Claims 1-16 and 18-20 rejected under 35 U.S. C. § 102(e) as anticipated by 

8 Haseltine. 

9 The Appellant argues claims 1, 2, 3, and 5 as a group. 

10 Accordingly, we select claim 1 as representative of the group, 
n 37 C.F.R. § 41.37(c)(l)(vii) (2007). 

12 The Examiner found that Haseltine anticipated claim 1. The Appellant 

13 contends that Haseltine fails to describe the report processor, portal interface 

14 element, and plural visual interfaces of claim 1 (Br. 8-9). We disagree with 

15 the Appellant. 

16 Report Processor 

17 Claim 1 requires the report processor be capable of allowing at least 

18 some of said plurality of billers to review and obtain reports in real time 

19 from data relating to said billers and the status of said biller's bills stored in a 

20 database. 

21 Haseltine' s system allows generating reports to billers and 

22 administrators (FF 09). The Appellant argues Haseltine has no teaching as 

23 to whether data is for billers or biller status. But having data for billers and 

24 biller status in Haseltine' s system and the capacity to generate reports, 
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1 Haseltine's system would be capable of allowing those described reports to 

2 access such data. There is no limitation on the manner in which such access 

3 is allowed; presence of the required data and the capacity to generate reports 

4 based on that data is sufficient to permit such access. 

5 Portal Interface Element and Plural Visual Interfaces 

6 Claim 1 requires a portal interface element capable of supporting a 

7 plurality of visual interfaces, each associated with a different web portal or 

8 bill presentment and payment website, each visual interface being supported 

9 by a web portal or bill presentment and payment website different from 

10 other of said visual interfaces 

1 1 There is no limitation regarding the manner of support. The Appellant 

12 argues there is no description of a portal interface element or of different 

13 visual interfaces (Br. 9). Visual interfaces per se are not recited as part of 

14 the claimed structure, only support for them. 

15 Haseltine allows a customer to log onto a Web site of a biller through the 

16 Internet via an HTML Secure Sockets Layer (SSL), which is a high-level 

17 security protocol that insures security of data transmitted over the Internet, 

18 and is well known and used by many commerce servers on the Web (FF 07). 

19 Such a logon portion of a web site is inherently a portion of the site's portal 

20 interface, since the code for an entry into a system such as a logon is a 

21 portal. Accordingly, Haseltine describes the portal interface element. 

22 Haseltine describes different interfaces for thin consolidators and thick 

23 consolidators. Haseltine allows thick and/or thin consolidators to preserve 

24 the " look- and-f eel" of their billers' bills while providing the customer with a 

25 flexible and integrated bill presentment and payment infrastructure (FF 08). 
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1 Further, Haseltine's bill data stream may be coded according to any 

2 number of formats such as the Open Financial Exchange (OFX) format, 

3 ASCII, extensible Markup Language (XML), print streams or other legacy 

4 or proprietary formats. The bill format data may include HTML-formatted 

5 data configured to mimic the "look-and-feel" of the biller's traditional paper 

6 bills, when rendered on a display device. Alternatively, or in addition to 

7 HTML, the bill format data may include functionality programmed in 

8 extensible Markup Language (XML) (FF 02). All of these have the capacity 

9 to support multiple visual interfaces. Accordingly, Haseltine describes the 

10 capacity for supporting such plural visual interfaces. 

n Claims 4, 6, 7, 8, 11, 12, and 18-20 

12 The Appellant separately argued claims 4, 6, 7, 8, 11, 12, and 18-20. 

13 Claim 4 requires the bill security element be adapted to utilize a third 

14 party credit verifier as said credit verifier. The Appellant argues Haseltine 

15 has no reference to a third party verifier (Br. 10-11). Claim 4 only requires 

16 capacity for a third party verifier, not the actual use of a third party. Such a 

17 capacity would require no more than access to Haseltine's system by a third 

18 party, since bill verification itself is one of the functions of Haseltine's 

19 system (FF 03). The logon logic we found described in Haseltine supra 

20 would allow any authorized party, including a third party to access the 

21 system as a credit verifier to verify Haseltine's bill data. 

22 Claim 6 requires the portal interface element be adapted to employ XML 

23 transmissions. The Appellant argues Haseltine describes transmitting 

24 HTML, but not XML (Br. 11). Claim 6 requires only the capacity to employ 

25 XML transmissions, not the actual transmission of XML. Haseltine's bill 
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1 format data transmissions may include functionality programmed in 

2 Extensible Markup Language (XML) (FF 02). Thus, Haseltine describes the 

3 capacity to employ XML transmissions. 

4 Claim 7 requires each consumer be authorized access to said database by 

5 a credit verifier during a particular consumer session on said visual interface 

6 only after an interactive session between the electronic bill presentment and 

7 payment system and the credit verifier which occurs during that consumer 

8 session. The Appellant argues the absence of a credit verifier precludes such 

9 an interactive session (Br. 11-12). The Appellant also argues claims 8-10 

10 and 13-16 as a group. Beyond the arguments made in support of claim 1, the 

1 1 Appellant argues that Haseltine fails to describe a portal interface element 

12 adapted to initiate an interactive session via a bill security element with a 

13 credit verifier to obtain authorization for a consumer to have access to 

14 information from a database (Br. 12-13). This is essentially the same 

15 argument as in support of claim 7. 

16 Haseltine describes an interactive session to obtain customer 

17 bioinformatic or other data for accessing the system (FF 10). As we found 

18 with claim 4 supra, Haseltine has the capacity for using such a third party 

19 credit verifier. The third party is not part of the claimed system. Rather 

20 claim 7 requires the preclusion from continuing into the system absent the 

21 claimed interactive session, which Haseltine' s system access logic provides. 

22 Claim 1 1 requires the bill report processor be adapted to allow a 

23 consumer to use one of the visual interfaces on a website to inquire online 

24 about the status of at least one bill, where the inquiry is conveyed to the 

25 particular biller. Claim 12 requires the bill data processor be adapted to 

26 allow the system to establish an interactive session between a consumer and 
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1 the particular biller. The Appellant argues that Haseltine does not describe 

2 these limitations (Br. 13-14). 

3 Haseltine allows customers to dispute bills by sending a message to a 

4 customer service representative. The biller of the disputed bill may then log 

5 onto the system and take appropriate action (FF 05). A customer service rep 

6 is associated with a biller. A message is adapted to allow any inquiry, 

7 including a status inquiry. The claim only requires the capacity for such an 

8 inquiry. We find that Haseltine thus describes such a capacity. 

9 Claim 18 requires the bill report processor be adapted to allow a 

10 consumer to select for review bills coming due on a certain date. Claim 19 

n requires the bill report processor be adapted to allow a consumer to select for 

12 review bills overdue. The Appellant argues these features are not described 

13 by Haseltine (Br. 14-15). 

14 Haseltine describes a template selection rule that compares the system 

15 date (i.e., the present date) with the bill due date and cause the template 

16 manager to select a biller- specific "overdue bill template" when the system 

17 date is greater than the bill due date and a "current bill template" otherwise. 

18 The template manager may also evaluate Boolean expressions such as AND, 

19 OR, etc. to select a template that is appropriate to the bill data (FF 06). 

20 Thus, Haseltine explicitly describes allowing review of overdue bills and 

21 describes the tools necessary to allow a consumer to select for review bills 

22 coming due on a certain date. 

23 Claim 20 requires the portal interface element be adapted to allow a 

24 consumer to pay bills from a plurality of different visual interfaces, each on 

25 a different site. The Appellant argues Haseltine fails to describe this (Br. 15- 
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1 16). We found that Haseltine described the capacity to use a plurality of 

2 different visual interfaces and a portal to access different sites in our analysis 

3 of claim 1 supra. 

4 The Appellant has not sustained its burden of showing that the Examiner 

5 erred in rejecting claims 1-16 and 18-20 under 35 U.S.C. § 102(e) as 

6 anticipated by Haseltine. 

7 Claim 17 rejected under 35 U.S.C. § 103(a) as unpatentable over Haseltine 

8 and Kamen. 

9 Claim 17 requires the portal interface element be adapted to allow a 

10 consumer to modify, online, the format in which a bill is presented on a 

n visual interface. The Examiner found that Kamen described allowing a user 

12 to so modify graphics (Answer 13-14). The Appellant argues that Kamen 

13 does not use bills or report processors (Br. 16-17). 

14 The Appellant responds to the rejection by attacking the references 

15 separately, even though the rejection is based on the combined teachings of 

16 the references. Nonobviousness cannot be established by attacking the 

17 references individually when the rejection is predicated upon a combination 

18 of prior art disclosures. See In re Merck & Co. Inc., 800 F.2d 1091, 1097 

19 (Fed. Cir. 1986). 

20 The Appellant has not sustained its burden of showing that the Examiner 

21 erred in rejecting claim 17 under 35 U.S.C. § 103(a) as unpatentable over 

22 Haseltine and Kamen. 
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1 CONCLUSIONS OF LAW 

2 The Appellant has not sustained its burden of showing that the Examiner 

3 erred in rejecting claims 1-16 and 18-20 under 35 U.S.C. § 102(e) as 

4 anticipated by Haseltine, or in rejecting claim 17 under 35 U.S.C. § 103(a) 

5 as unpatentable over the prior art. 

6 DECISION 

7 To summarize, our decision is as follows: 

8 • The rejection of claims 1-16 and 18-20 under 35 U.S.C. § 102(e) as 

9 anticipated by Haseltine is sustained. 

10 • The rejection of claim 17 under 35 U.S.C. § 103(a) as unpatentable 

1 1 over Haseltine and Kamen is sustained. 

12 No time period for taking any subsequent action in connection with this 

13 appeal may be extended under 37 C.F.R. § 1.136(a)(l)(iv). 

14 

15 AFFIRMED 

16 
17 

18 vsh 

19 
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